[レポート]Windows Event Log Internals: コアメカニズムを理解してセキュリティレベルをアップする – CODE BLUE 2023 #codeblue_jp
CODE BLUE 2023で行われた以下のセッションのレポートです。
Windows Event Log Internals: コアメカニズムを理解してセキュリティレベルをアップする
Windows Event Logに関しては、分析方法やログをパースする方法が主要な話題となることが多い。しかし、インシデント分析の場面ではログ分析以外にもログファイルが壊れている際の回復方法や削除されたログの復旧方法、Windows Event Log調査ツールを使用する場面ではログフォーマットの知識が必要になる場面もある。本プレゼンテーションでは、Windows Event LogのフォーマットやWindowsの内部構造に焦点を当て、その理解を通じてセキュリティ対策を強化する方法を紹介する。具体的には、カスタムWindows Event Logの作成方法やWindows Event Logの悪用の問題に対処する方法および我々が開発したツールについて紹介する。 はじめに、本プレゼンテーションでは、Windows Event LogとそのAPI Callフローについて解説し、EVTXファイルフォーマットについて説明する。そして、カスタムWindows Event Logを作成するツールをデモを交えて紹介する。さらに、Windows Event Logを攻撃に利用する手法について解説し、Windows Event Log内にマルウェアの情報を隠蔽する方法やログ分析を困難にする手法などを紹介する。また、カスタムWindows Event Logを使用したアンチフォレンジック手法についても紹介する。最後に、Windows Event Logを利用した攻撃を検知する方法や改ざんされたイベントログを特定する手法を説明する。 このプレゼンテーションを通じて、Windows Event Logの内部構造をより深く理解し、その知識を活用してシステムやネットワークのセキュリティを向上させることができる。
Presented by : 朝長 秀誠 - Shusei Tomonaga
レポート
- Windowsのイベントログについての話
- どうやってログを分析すればいいのか?ということがまず想起されるが、ログをどう復旧すればいいのか、なども現場では問題になる
- そのため、分析以外の知識も必要となる
- イベントログとはなにか?
- Windows OSに関する各種ログ
- MS-EVENとMS-EVEN6が2種類ある
- MS-EVEN6の「6」はバージョン番号だが、6までは付いていなかった
- なのでMS-EVENが旧バージョン
- MS-EVEN(旧バージョンについて)
- WinAPIから呼び出す
- APIコールすると、内部でネイティブAPIに変換されたあと、RPC経由で命令が伝わる仕組み
- RPC経由での中継の際に、NdrClienCall3というAPIがコールされるが、MSの公式ドキュメントでも詳細が不明
- 第二引数がRPCの命令番号
- 受信側ではこの命令番号をもとに命令を実行する
- 命令番号とRPC番号は1対1で対応している。番号は26まで確保されているが、使用されていないものや直接呼び出せない(ネイティブAPIを使う必要のある)ものもある
- MS-EVEN6
- WMIやWevtutil,ETW Appなど経由で利用できる
- ETW:Event Tracing for Windows
- ETW経由でのログ出力の拡張子は".etl"
- MSがEVTXやJSONに変換する方法を提供している
- 旧MS-EVEN同様RPC経由でも利用できる
- WMIを利用しても最終的にRPCを経由
- 命令番号の仕様が旧バージョンと異なる
- 28番まである(旧バージョンは26まで)
- APIと命令番号が1対1対応ではない
- 一つの命令を複数のRPC命令で処理する場合があるため
- 単一のAPIで複数のRPC命令を処理できる
- WMIやWevtutil,ETW Appなど経由で利用できる
- ログフォーマットについて
- EVTX形式のファイルでは、イベントレコード単位で記録しており、複数のイベントレコードが「チャンク」としてまとめられており、複数のチャンクでファイルが構成される3層構造
- ファイルヘッダ:ElfFileというシグネチャから始まる
- チャンクサイズ、チャンク数などがヘッダに記録されている
- その後チャンクのデータが続いている
- チャンクサイズは0x10000以下
- チャンクヘッダ:ElfChnkというシグネチャから始まる
- 最初のレコード番号、最後のレコード番号などの情報がヘッダに記録される
- イベントレコード:
- 日付情報に続いてバイナリXMLでイベントデータが記録される
- テンプレートが最初に記録され、後のデータはそのテンプレートを参照する
- 実際のイベントのバイナリXMLはサイズの情報→実際のデータの情報が入っている
- 日付情報に続いてバイナリXMLでイベントデータが記録される
- イベントログの再構築
- EVTXはパースするツールはいろいろある
- EVTXファイルを再構築するにはどうすればよいか?
- XML2EVTXというツールをJPCERTがリリースした(JPCERTのgithubリポジトリ上にある)
- Python製、コマンドラインで動作。XMLからEVTXバイナリを生成できる
- 生成したEVTXバイナリはイベントビューア上でも見ることができる
- EVTXの元になるXMLをどう作ればいいのか?(ランダムなデータのログがほしい場合など)
- XML2EVTXとセットで、ランダムのデータを生成するスクリプト(Python製)もリリースしている
- デモ
- 1000件のランダムなイベントログを作成
- XML2EVTXで、チャンク形式で分割してEVTXバイナリを生成できる
- 生成したバイナリはこちらもイベントビューアで確認できるようになる
- Attack Surface
- イベントログは悪用できるか?→すでに悪用されている。イベントログにシェルコードを隠す手法が出てきた
- どういった攻撃ができるか?
- MaliciousなURLをEVTXファイルに隠せるか?
- -> 可能、通常のビューでは見えないがXMLのスキーマに隠すということができる
- マルウェア自体をログに隠せるか?
- -> 可能。Base64でエンコードすることでログ内に埋め込める
- マルウェアを埋め込んだEVTXのリンクを利用者が開くと、表示上はビューアでイベントログを開いているように見えるが、裏ではマルウェアを読み込んでしまい、動作してしまう
- 大量のログがあるフォルダにこうしたファイルを紛れ込ませてしまうと気づけなくなる可能性がある
- 悪意のあるログを見せないようにする工夫
- いくつかのヘッダを偽装することでログを隠蔽することが可能
- チャンクヘッダの開始番号・終了番号を操作することでイベント数をごまかし、悪意ある(マルウェアなどが隠された)ログを見えなくすることができる
- イベントヘッダのサイズの情報を偽装することで、あるサイズ以降のデータを見せなくする、レコード番号を偽装することも可能
- ログの汚染について
- ログに悪意あるコードを追加して再構築することで、ログのバイナリの改ざん(汚染)が可能になる
- デモ
- セキュリティログをXML形式でエクスポート
- エクスポートしたログに悪意あるコードを追加して上書き
- 一旦イベントログのサービスの終了が必要
- XML2EVTXでXMLをEVTXバイナリを再構築しセキュリティログを置き換え
- イベントログサービスを再起動
- セキュリティログを見ると、改ざんされた情報が含まれている
- MaliciousなURLをEVTXファイルに隠せるか?
- 攻撃への対処
- 重要な点
- 管理権限を取られないようにする
- EVTXファイルのバックアップをする
- EVTXファイルのスキャンをする
- ログの改ざんや隠蔽の検知
- ヘッダ情報内のチェックサムをチェック
- イベントログの解析の際はパースツールを利用する
- チェックサムをチェックしてくれたり、隠されたログを表示させたりできる
- イベントビューアをなるべく使わない
- イベントビューアは正しいフォーマットであることを想定しており、情報が隠蔽されたログの検知は難しい
- 各要素の前にハッシュ値を持っているため、このハッシュ値をチェックする方法もある
- ただし、対応しているツールがいまのところないかもしれない
- SDBMというアルゴリズムが使われている
- 重要な点
感想
- Windowsイベントログについて、仕様から考えられる攻撃方法まで濃い紹介でした!Windowsイベントログについての知識が深まりました。